Clean up module outputFile calculation and move it to the specifications#6967
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
We detected some changes at Caution DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release. |
|
🤖 Code Review · #projects-dev-ai for questions ✅ Complete - No issues 📋 History✅ No issues → ✅ 2 findings → ❌ Failed → ✅ No issues |
59f0139 to
7b9999e
Compare
bbc0817 to
7b68eb7
Compare
Coverage report
Test suite run success3833 tests passing in 1480 suites. Report generated by 🧪jest coverage report action from 2151198 |
7b68eb7 to
c3ee349
Compare
24fb214 to
ecf7d0f
Compare
9bebf7c to
dd63de8
Compare
7e38d07 to
880b269
Compare
5647756 to
dcffdf5
Compare
dcffdf5 to
b7dd050
Compare
a8cf663 to
40c8534
Compare
40c8534 to
72e5cc8
Compare
72e5cc8 to
2151198
Compare
|
This PR seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. |

WHY are these changes introduced?
The
outputFileNameproperty was previously calculated dynamically using a getter method that relied on the extension's build configuration mode. This approach was inflexible and didn't allow for extension-specific customization of output file names.WHAT is this pull request doing?
outputFileNamefrom a computed getter to a direct property onExtensionInstancegetOutputFileNamemethod to theExtensionSpecificationinterfacegetOutputFileNamein all UI extension specifications to return${extension.handle}.jsgetOutputFileNamein function extensions to returnindex.wasmBuildConfigtype to use a discriminated union for better type safetyoutputFileNamein the constructor using the specification's method or defaults to empty stringHow to test your changes?
Measuring impact
How do we know this change was effective? Please choose one:
Checklist